Monitoring, testing and measuring packet switched IP networks may involve the use of inline unaddressed eavesdropping devices and corresponding controllers to minimize the changes to the network under test.
In non-MPLS networks, such as a purely IP network, replying to a controller's packet may be accomplished by an inline unaddressed eavesdropping device setting the reply packet's destination address as the controller packet's source address then sending the reply packet back upstream towards the controller. The routing architectures of non-MPLS networks ensure that the reply packet will reach the specified destination address. However, within an MPLS (Multiprotocol Label Switching) network, labels, and not IP addresses, control the routing of packets. Because MPLS labels are assigned at the edges of MPLS networks and the labels are different for opposite directions on the same path, there is no existing mechanism for an unaddressed eavesdropping device inline within the MPLS network to originate communications to other devices, for example, sending a reply packet back upstream to its controller.
Multiprotocol Label Switching (MPLS) is a protocol or forwarding mechanism in packet-switched networks that directs data from one network node to the next based on short (e.g. 20-bit) path labels rather than long network addresses (e.g. IPv4's 32-bit addresses or IPv6's 128-bit addresses). MPLS operates at a layer that is generally considered to lie between traditional definitions of layer 2 (data link layer) and layer 3 (network layer) of the OSI (Open Systems Interconnection) model, and thus may be referred to as a “layer 2.5” protocol.
MPLS is designed to determine packet routing paths, in the form of labels, when a packet enters the MPLS network so that subsequent nodes in the path do not incur the costs of making routing decisions at each and every hop. MPLS also allows for more flexible routing of packets and potentially faster routing by internal network nodes because the packet contents do not need to be inspected at each hop. One side effect of concentrating the routing decision-making at the edges routers of an MPLS network is that changing the routing path becomes more difficult after the packet enters the MPLS network. MPLS labels are assigned by the edge routers and describe the path to be taken through the network.
The path to be taken is decided when a packet enters the MPLS network at a Label Edge Router (LER) or ingress router. An LER can consider much more information than a packet's destination address when deciding on a desired path through the MPLS network. LERs are sufficiently aware of the MPLS network topology and sufficiently able to analyze packets and other information to select appropriate routing paths. A packet's routing path is set in the form of labels that are typically pre-pended to the packet.
Labels may describe the selected routing path between distant nodes rather than endpoints or individual hops to the next node. There can be more than one label assigned to a packet and this is generally described as a label stack. MPLS uses different labels for each direction of traffic through a path.
Labels may correspond to IP destinations in networks (similar to traditional IP forwarding), but labels may also correspond to, or may incorporate, other parameters, such as account information based on the routing table entry (e.g. destination, bandwidth, delay, and other metrics), a header field (e.g. source address), Layer 4 socket number information, QoS (Quality of Service), differentiated service, traffic engineering, the status, functionality and load of the network, previous labeling decisions, and any other information available to the network operator and/or the LER. Consequently, MPLS gives network operators a great deal of flexibility to decide how to prioritize and route traffic as it appears at an LER.
Once an LER has set a packet's labeling, the packet may be forwarded through nodes internal to the MPLS network. Generally, no further inspection of the packet contents is necessary until the packet leaves the MPLS network through an egress router, which pops the label and inspects the packet to determine what should be done next. Packet routing decisions at internal nodes are made based on the contents of the label, or the topmost label in a stack of labels, generally without incurring the overhead of examining the packet contents or other labels in the stack, if any.
When a packet is routed through an IP network that does not include MPLS, each node in the network that receives the packet forwards the packet based on a look up of the packet's destination address in its routing table. Each node makes its routing decisions independently of the routing decisions of other nodes and it is generally not possible for a node to influence how a specific packet is routed by other nodes. IP routing tables are typically maintained on each node and are designed so that packets are routed on a path through the fewest nodes or fewest hops. Network congestion, preferential treatment and other factors are not generally considered; rather, each node tries to make its decision independently, based only on the routing table look up. In this way, an IP network that does not include MPLS attempts to minimize the number of routing decisions that must be made (i.e. fewest hops) and minimize the time required for any node to independently make a routing decision.
In contrast, an MPLS network typically incurs most of the routing decision-making costs when a packet enters the MPLS network so that none of the internal nodes need to inspect the packet. In this way, an MPLS network promotes flexibility in selecting a routing path when a packet enters the network, but is inflexible when changes need to be made to the routing path within the MPLS network.
A complete discussion of MPLS networks and their differences over non-MPLS networks is beyond the scope of this disclosure.
Referring now to FIG. 1, an existing non-MPLS network 100 is illustrated. Non-MPLS network 100 includes an intelligent packet director (IPD) 102 an IPD controller 104, device A 106 and device B 108.
The IPD 102 is a type of unaddressed device that has a unique identifier and is placed inline into any network path between two nodes (not illustrated). Typically, IPDs 102 surreptitiously inspect both directions of traffic on that path to test, measure or monitor the network. The inline placement of the IPD 102 on a network path means the IPD 102 receives traffic on an upstream side and a downstream side. For simplicity of explanation, this disclosure shall assume the convention that the upstream side is the side from which the IPD last received a packet from a controller containing the IPD's unique identifier. Other conventions or directions of traffic flow are equally within the scope of this disclosure. In this disclosure, upstream and downstream sides are used to denote opposite sides of a device and not intended to limit the location of devices within a service provider's network.
The IPD 102 has four ports to accommodate its inline placement and traffic monitoring in a bidirectional network path. As illustrated in FIG. 1, these four ports are a downstream input port 130 a downstream output port 132, an upstream input port 134 and an upstream output port 136. By inspecting the incoming traffic 110, 112 through both input ports 130, 134, existing IPDs 102 can identify that the IPD controller 104 and device A 106 are upstream while device B 108 is downstream. In the Figures, the upstream and downstream traffic of the various devices have been divided for easier visual identification. Although the IPD 102 is inline on a path between device A 106 and device B 108, A's downstream traffic 110 departing the IPD 102 through port 132 may be destined for any device downstream of the IPD 102, not necessarily including device B 108. Similarly, B's upstream traffic 112 departing the IPD 102 through port 136 may be destined for any device upstream of the IPD 102, not necessarily the IPD controller 104 or device A 106.
After discovery, the IPD controller 104 communicates with the IPD 102 by sending a command packet 114, such as a SmartOptics™ command packet (SOCP), containing the IPD's 102 unique identifier to an address known to be downstream of the IPD 102. In FIG. 1, this device could be device B 108. The command packet 114 may contain commands that are sent from the IPD controller 104 or packet routing engine (PRE) to the IPD 102, commands such as timing, keep alive, etc. The IPD 102 is inline between nodes and recognizes the unique identifier in the command packet 114 that indicates that the packet is intended for the IPD 102. When the IPD 102 identifies its unique identifier in the command packet 114, it consumes the packet 114, removing it from the network, and processes the data of interest in the command packet 114. The IPD 102 associates the source address information (src) from the command packet 114 with the IPD controller 104. In this manner, the IPD 102 can be an unaddressed device (borrowing IP/MAC or other addressing information of any active downstream network device), receive packets 114 from its upstream IPD controller 104 and acquire the address information of the IPD controller 104.
In a non-MPLS network 100, existing IPDs 102 can reply to the IPD controller 104 in the traditional way: sending a reply packet 116 back upstream using the IPD controller's 104 address information as the destination address (dst). If network 100 was a purely IP network, this would simply involve inserting the IP and MAC address of the IPD controller 104 into a response packet 116 sent through the upstream outgoing port 136 of the IPD 102.
Turning now to FIG. 2, the non-MPLS network 100 of FIG. 1 is illustrated in another condition of operation. The IPD 102 surreptitiously inspects incoming traffic 110 from device A 106 and/or incoming traffic 112 from device B 108 for content of interest that matches filters (not shown) loaded into the IPD 102. If a packet of traffic 110, 112 matches a filter, a copy of the packet is taken from the link, as it passes through the IPD 102, and placed into a Filter Results Packet (FRP) 118, 120 corresponding to each of device A 106 and device B 108. As illustrated in FIG. 1, the IPD 102 may receive a command packet 114 (not shown in FIG. 2) instructing the IPD 102 to send back any accumulated filter result packets to the IPD controller 104. Similar to FIG. 1, an FRP 118, 120 packet may be sent back to the IPD controller 104 by sending the FRP 118, 120 out the upstream output port 136 with destination address information (dst) corresponding to the IPD controller 104.
However, if network 100 were an MPLS network, reply packets 116 and FRPs 118, 120 could not be sent directly to the IPD controller 104 by sending those packets back upstream through upstream output port 136. In MPLS, packets are routed based on labeling and not based, for example, on destination IP and/or MAC address information. Labeling is assigned to packets at an edge router or ingress router and may comprise a single label or a stack of labels. Internal nodes in an MPLS network, such as transit routers, do not inspect packet contents. Internal nodes merely look up the label in a label routing table to determine how to forward the packet. Because upstream and downstream labels on a path of an MPLS network are different, it is non-trivial for an existing IPD 102 that is inline on a path of an MPLS network to know the labeling necessary to reply to its IPD controller 104. Further, it is not possible to know this information merely by receiving a command packet 114 from the IPD controller 104. The included IPD controller's address information and the downstream labeling received with the controller's packet is insufficient information to send a reply packet 116 upstream to the IPD controller 104 in an MPLS network. More generally, it is non-trivial for any IPD 102 in an MPLS network to send a packet to a device when the IPD 102 has not already monitored packets being sent to that device from somewhere else in the network and the IPD 102 has recorded the required MPLS labeling.